“Hacer post-mortems sin culpables” es el mantra de SRE desde que Google lo popularizó. Todo el mundo asiente. Pocas organizaciones lo hacen bien. Entre el concepto y la práctica hay una distancia que la mayoría de equipos no consigue cerrar — y el resultado es un ritual vacío: plantillas rellenadas que nadie lee, action items que nadie ejecuta, y los mismos incidentes repitiéndose.
Este artículo es sobre cómo hacer post-mortems que realmente producen aprendizaje y cambios — con técnicas concretas, no buenas intenciones.
Por qué fracasan los post-mortems “oficialmente blameless”
Los patrones de fracaso son reconocibles:
- Blame disfrazado. El post-mortem dice “no hay culpables” pero la narrativa deja claro quién falló. La persona implicada lo sabe. El blameless es performativo.
- Narrativa oficial sanitizada. Lo que ocurrió realmente se suaviza para no ofender stakeholders. El aprendizaje real queda en conversaciones privadas.
- Action items teatrales. “Añadir más monitoring” / “Mejorar documentación”. Vagos, sin owner, sin plazo. Nunca se cumplen.
- No leer los post-mortems antiguos. Cada incidente parece nuevo porque nadie mira si ya ocurrió.
- Solo los grandes van a post-mortem. Pierdes el aprendizaje de near-misses, que son más valiosos.
Reconocer estos patrones es el primer paso para hacerlo bien.
Los tres elementos no negociables
Un post-mortem decente tiene:
- Una línea temporal factual de qué ocurrió, cuándo, quién lo vio primero, qué se hizo.
- Un análisis honesto de contribuyentes — no solo “qué falló” sino “qué hizo fácil o posible que fallara”.
- Action items específicos con owner y plazo, cuyo cumplimiento se rastrea.
Sin los tres, es papel mojado.
Línea temporal: los detalles importan
La timeline debe responder:
- T-0: qué sucedía antes del incidente. A menudo revela un trigger olvidado (deploy, cron, cambio de config).
- T + n: momento del fallo inicial. ¿Quién vio primero? ¿Cómo? (alerta, cliente, casualidad).
- Escalado: cómo llegó a la persona correcta. Si tardó demasiado, es proceso, no persona.
- Mitigación: qué funcionó, qué no, qué se intentó primero.
- Recuperación: cuándo volvió el servicio.
- Follow-up: cuándo se cerró oficialmente.
Tiempos en UTC o zona clara. Mejor timestamps demasiados que demasiado pocos.
El problema con los “5 porqués”
5-whys es técnica tradicional: ¿por qué falló X? Por A. ¿Por qué A? Por B. Y así hasta la “causa raíz”.
Problema: asume causa lineal y única. Los incidentes reales son multicausales. Tres servicios se alinean mal a la vez. Una alerta existía pero el pager estaba mal configurado. Un runbook existía pero no se encontró.
Mejor alternativa: pensar en contribuyentes, no causas raíz. Lista de factores que individualmente no hubieran causado el incidente, pero juntos sí. Cada uno merece acción.
Técnicas de entrevista blameless
En la reunión de post-mortem, el facilitador marca la diferencia. Técnicas que funcionan:
- Preguntar “qué información tenías”, no “por qué tomaste esa decisión”. La decisión se explica por la información disponible, no al revés.
- Cronología antes de interpretación. Primero pactar qué pasó en cada momento; luego discutir por qué.
- Mencionar persona por rol, no por nombre, en el documento. “El on-call” en vez de “Juan”. Evita que leerlo meses después enfoque en quién.
- Normalizar errores humanos. “Cualquiera en esa posición con esa información habría hecho lo mismo” — si es cierto, decirlo.
- Separar observaciones de juicios. “La alerta tardó 7 minutos en dispararse” (observación) vs “la alerta tardó demasiado” (juicio).
Un facilitador entrenado cambia el tono de la sala.
Action items que se cumplen
Los action items mal definidos son el cementerio de post-mortems. Los que se cumplen tienen:
- Owner específico. Una persona, no un equipo. Si es un equipo, nadie hace nada.
- Plazo acotado. “En Q1” es demasiado vago. “Para el 28 de febrero” aterriza.
- Criterio de cumplimiento claro. No “mejorar monitoring” — “añadir alerta X con threshold Y, revisada por Z”.
- Rastreo centralizado. Un sistema (Jira, Linear, GitHub Issues) donde todos los action items viven. Revisión mensual.
- Proporcionalidad. No 20 action items por incidente. Priorizar 3-5 que de verdad muevan la aguja.
Un action item sin plazo no se cumplirá. Un action item con plazo pero sin seguimiento, tampoco.
El archivo: buscar antes de entrar
Antes de un post-mortem nuevo, buscar post-mortems antiguos similares. Patrones comunes:
- Misma causa, misma mitigación, misma lección teórica. Los action items no se cumplieron.
- Causa distinta pero categoría similar. Hay un issue sistémico.
- Incidente predicho en un post-mortem antiguo pero no priorizado.
Una wiki o carpeta buscable con todos los post-mortems es oro. Grepeable > formateada bonita.
El meta-post-mortem
Trimestralmente, mirar los post-mortems acumulados:
- ¿Qué action items estaban abiertos y vencieron?
- ¿Qué patrones se repiten?
- ¿Qué no estamos aprendiendo?
- ¿Hay inversiones estructurales que habrían evitado varios incidentes?
Este meta-análisis es lo que convierte a organizaciones de “apagar fuegos” a “construir resiliencia”. Sin él, el ciclo es infinito.
Incidentes pequeños también
La mayoría de organizaciones solo hace post-mortem de incidentes SEV-1. Pero los aprendizajes más baratos vienen de SEV-3 y near-misses — eventos donde casi pasa algo grave pero se detectó a tiempo.
Modelo light para incidentes pequeños:
- 5 líneas de timeline.
- 3 contribuyentes.
- 1-2 action items específicos.
Sin reunión formal. En Slack o issue. El volumen de aprendizaje pequeño, sumado, supera el de unos pocos grandes.
Plantilla práctica
Una plantilla mínima viable:
## Resumen
[2 párrafos: qué pasó, impacto cliente, duración]
## Timeline
- 14:02 UTC - Deploy de servicio X versión 1.4.2
- 14:15 UTC - Primera alerta: latencia p99 >2s
- 14:17 UTC - On-call recibe page
- 14:20 UTC - Rollback iniciado
- 14:35 UTC - Servicio restaurado
## Impacto
- Clientes afectados: ~15% de tráfico
- Duración del impacto: 20 min
- Revenue impact: $X (si aplica)
## Contribuyentes
1. Cambio incluía query N+1 no detectado en staging (load bajo).
2. Alerta de latencia configurada a 5 min de retraso.
3. Runbook de rollback desactualizado.
## Lo que funcionó bien
- On-call reaccionó rápido.
- Rollback procedure funcionó cuando se ejecutó.
## Action items
- [ ] @alice: añadir slow-query detection al CI, deadline 22/02.
- [ ] @bob: reducir delay de alerta p99 de 5min a 2min, deadline 15/02.
- [ ] @carol: actualizar runbook rollback con pasos actuales, deadline 20/02.Enlaces a código, dashboards, tickets.
Cultura: el factor que no se ve
Las técnicas ayudan pero la cultura decide. Señales de cultura saludable:
- Un ingeniero junior puede decir “rompí producción” sin miedo.
- Los líderes hablan abiertamente de sus propios errores.
- Se celebran las lecciones aprendidas, no se ocultan.
- Recursos para action items son prioridad, no afterthought.
- Métricas de salud del proceso (action items cumplidos, tiempo a publicar post-mortem).
Cambiar cultura lleva años. Empezar con técnicas es el camino — con el tiempo, la cultura se adapta.
Conclusión
Post-mortems blameless son una herramienta potente cuando se hacen bien. La diferencia entre teatro y aprendizaje real está en los detalles: timeline factual, contribuyentes honestos, action items con owner y plazo, seguimiento continuo, revisión trimestral del patrón. Lleva tiempo instaurar la práctica, pero el retorno es real — organizaciones que lo hacen bien tienen menos incidentes repetidos y equipos que no queman por el peso de problemas no resueltos. El coste mayor está en el rigor, no en la técnica.
Síguenos en jacar.es para más sobre SRE, cultura de operaciones y gestión de incidentes.
